refactor: rename overloaded constructors to from* names [codex]#255
refactor: rename overloaded constructors to from* names [codex]#255jderochervlk merged 26 commits intomainfrom
Conversation
Port the surviving API cleanup from the final pre-alpha branch onto the monorepo split introduced in #249. This adds the missing concrete modules, translates the fetch/runtime/canvas/websocket/media surface cleanup into the package layout, and keeps the branch green with updated tests.
Drop scroll2/scrollTo2/scrollBy2 and keep the descriptive *XY overload names requested in review. Co-authored-by: Codex <codex@openai.com>
…with-commits-and-responses Address review feedback: rename constructors, unbox FormDataEntryValue, reuse MessageEvent types, simplify tests
…-webapi into codex/issue-236-constructor-from-names-carryover
Update DOMMatrix, DOMMatrixReadOnly, Path2D, and ReadableStream single-source constructor overloads to take direct unlabeled arguments. Refresh compile-coverage tests and contributor documentation to match the constructor naming convention.
Remove source-shape callouts from the constructor docs added in this PR. Rewrite constructor summaries to focus on the ReScript API surface and update the contributor documentation guidance to match.
jderochervlk
changed the title
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2c7ece03a2
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
tsnobip
left a comment
tsnobip
left a comment
There was a problem hiding this comment.
except from the sharedArrayBuffer, the rest looks good to me!
Replace the unknown SharedArrayBuffer-only constructor surface with a typed-array overload alongside the existing ArrayBuffer and DataView bindings. Update the compile-coverage test to exercise the new VideoFrame.fromTypedArray binding.
brnrdog
left a comment
brnrdog
left a comment
There was a problem hiding this comment.
Looks good, just non-blocking questions. I liked how the constructor overload pattern is documented.
| external fromUnderlyingSourceWithStrategy: ( | ||
| ~underlyingSource: Types.underlyingSource<'t>, | ||
| ~strategy: Types.queuingStrategy<'t>, | ||
| ) => t<'t> = "ReadableStream" |
There was a problem hiding this comment.
Not a blocker, I'm more curious about the right pattern. Would it make sense to have underlyingSource just as a positional argument and keep the strategy as a labeled one? It'd feel a bit more consistent with the other constructors, something like:
external fromUnderlyingSourceWithStrategy: (
Types.underlyingSource<'t>,
~strategy: Types.queuingStrategy<'t>,
) => t<'t> = "ReadableStream"as we have fromUnderlyingSource as:
external fromUnderlyingSource: Types.underlyingSource<'t> => t<'t> = "ReadableStream"There was a problem hiding this comment.
Or maybe having only one function with an optional strategy labelled argument
There was a problem hiding this comment.
Yeah, I like the one function with the first argument being positional and the ~strategy being optional.
3 participants
Summary
from*source-type namesmake()VideoFramepixel-data constructors as separateArrayBuffer,TypedArray, andDataViewbindingsmainValidation
npm testnpm run format:checkASTRO_TELEMETRY_DISABLED=1 npm run build:docs